feat(auth): accept sktsec_-prefixed Socket API keys as Bearer tokens#187
Merged
Conversation
bc87dcc to
3ce6aec
Compare
A client could only authenticate to an OAuth-enabled HTTP deployment with an OAuth access token: routeRequest ran every Bearer token through introspection, so a raw Socket API key was rejected as invalid_token. Recognize a Socket API key by its `sktsec_` prefix on the standard `Authorization: Bearer` header and apply it directly to req.auth, skipping introspection. OAuth access tokens (no prefix) still flow through introspection unchanged, and non-OAuth mode is unaffected. This lets a caller authenticate with a raw Socket key over the same header in both modes, with no custom header. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3ce6aec to
4a01ea4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A client could only authenticate to an OAuth-enabled HTTP deployment (e.g.
https://mcp.socket.dev/) with an OAuth access token.routeRequestran everyAuthorization: Bearertoken through OAuth introspection, so a raw Socket API key was rejected asinvalid_token. A config like this failed:Change
Recognize a Socket API token by its
sktsec_prefix on the standardAuthorization: Bearerheader and apply it directly toreq.auth, bypassing introspection. The auth dispatch is now:sktsec_-prefixedapplyClientApiKey(unchanged)This keeps the same header working in both modes — no custom header needed — and leaves OAuth and non-OAuth behavior otherwise untouched.
The API-key helpers were extracted into
lib/http-auth.ts(keepshttp-server.tsunder the 500-line lint cap); the test file was renamed to match.Note
This trusts the
sktsec_prefix as the discriminator between Socket API tokens and OAuth access tokens — consistent with theSOCKET_PUBLIC_API_TOKENconstant in@socketsecurity/lib.Verification
pnpm run lint✅pnpm test— 144 passed ✅pnpm run test:tsc✅Local manual test (OAuth off):
MCP_HTTP_MODE=true SOCKET_API_TOKEN=<sktsec_...> node --experimental-strip-types index.ts --http, then pointmcp-remoteathttp://localhost:3000/with--header "Authorization: Bearer sktsec_...".🤖 Generated with Claude Code